CPSC 521 Assignment 8

In 1998, Brin and Page [2] identified the need for an Internet search engine capable of scaling to a huge size. They foresaw the explosion of the number of web pages to continue, making human maintained lists of web pages more expensive and less effective. They explain that with this increase in web pages comes an increase in matching pages per query, and thus the ranking system must be more accurate to ensure quality matches in the top 10 or 20 returned. Also increasing is the number of search queries which suggests a high throughput is needed. With these points in mind, they design data structures to be distributed and scale gracefully. However, they note that while technology trends have CPU speed and disk size increasing rapidly, disk seek time and OS robustness may not improve as quickly and become concerns. The use and economy of Google clusters is described in [1]. Queries parallelize easily, with each running on many processors that each search a part of the index. Clusters are located worldwide where search queries serviced by a geographically nearby cluster with available computing power. Once a query is sent to a particular cluster, index server computers map the query words to actual documents generating a hit list data structure, described in [2]. The search index is tens of terabytes distributed randomly into index shards local to index servers. The list of documents returned is in the form of docids, a unique web page identifier. This is sent to a group of document server computers, each searching its own randomly distributed set of web pages. Document servers return the web page title and the keyword-in-context snippet as seen in Google search results. This is sent to one of many cluster web servers where the HTML for search results is generated and returned to the user’s web browser. These clusters are build from commodity x86 PCs connected with Ethernet switches. At of the time of publication of [1], these ranged from 533 MHz Celerons to dual 1.4 GHz Pentium IIIs each with one or more local IDE hard drives. They argue the economy of a cluster built from this commodity equipment. An example is given where a commodity cluster costs three times less, has 22 times the processors, has three times as much RAM and slightly less disc space than a highly integrated multiprocessor server. Of course, the high-end server is more reliable and has lower communication latency, but these are not critical to the cluster. Network traffic is expected to be low due to the highly parallelized application, and failures are handled by a fault tolerance scheme based on replication [4]. Failed equipment such as disk drives and power supplies are batched and replaced regularly. Though highly integrated multiprocessors may not be economically viable, they do give performance gains. In [1] they explain that their application does not exhibit much instruction level parallelism. In fact, they state that the 4 instruction issue Pentium 4 gives worse performance than the 3 instruction issue Pentium III. Parallelism is realized at the thread level where it is trivially exploited. This points to simultaneous multithreading (SMT) and chip multiprocessors (CMP) for performance gains. SMT has obvious benefit here since threads likely spend a long time stalled on cache misses, disk seeks and mispredicted data-dependent branches. Indeed, they claim that performance is increased by 30 percent on a dual-context SMT. CMPs could yield an even greater performance gain. Systems like the Piranha, or more recently, the Niagra [5] are designed for execution of multiple threads that block frequently. They use chip space to give Google’s application exactly what it needs: multiple processors with multithreading, short, inorder pipelines and a large L2 cache. However, the cost of something like the Niagara chip could outweigh its benefit. Google uses clusters for tasks other than performing web searches, such as building the search index data structure (called the inverted index). While these tasks are easily parallelized, there are the issues of how to distribute data and deal with failures. Ideally, as much information as possible about the cluster execution should be abstracted from the programmer. A method of achieving this abstraction is MapReduce [3]. This technique can be used for computations where the input and output are key/value pairs. The user writes a map function that computes intermediate key/value pairs from input key/value pairs. Pairs with the same intermediate key are grouped and sent to a reduce function (also